Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links, segments and sub-networks. These entities are typically software processes executing on hardware computer platforms, such as end nodes and intermediate nodes. Communication software executing on the end nodes correlate and manage data communication with other end nodes. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
An intermediate node, such as a router or switch, executes routing protocols used to direct the transmission of data traffic between the end nodes, such as hosts or users. Typically, the router directs network traffic based on destination address prefixes contained in the packets, i.e., the portions of destination addresses used by the routing protocol to render routing (“next hop”) decisions. Examples of such destination addresses include Internet Protocol (IP) version 4 (IPv4) and version 6 (IPv6) addresses. A prefix implies a combination of an IP address and a mask that cooperate to describe an area or range of the network that a router can reach, whereas a route implies a combination of a set of path attributes and a prefix.
A local area network (LAN) is an example of a subnetwork that provides relatively short distance communications among the intermediate nodes. A wide area network (WAN) enables log distance communication over paths provided by public or private telecommunication facilities. The Internet is an example of a WAN that connects disparate computer networks throughout the world providing global communications between nodes and various networks. A router or switch may interconnect sub-networks to extend the effective “size” of the computer network. However, the router or switch that joins to LAN's is often called a “last hop,” or an edge router or switch, since it resides at the “edge” of the Internet. In this application “edge router,” “edge switch” or “switch” are used synonymously to designate this edge device.
Unicast data transfer (i.e., unicast forwarding) involves forwarding a data packet from a single sending process of an end node (“source”) to a single receiving process of an end node (“receiver”) on the computer network. Often the destination of the data packet issued by a source may be more than one, but less than all of the receivers on the network. This type of multicast data transfer (i.e., multicast forwarding) is typically employed to segregate communication between groups of receivers on the network. IP multicasting, in particular, may be used to disseminate data to a large group of receivers on the network.
To effect IP multicasting, the source generally specifies a destination IP address that is a multicast group address for the message and, as such, can only represent receivers of packets. The IPv4 (or IPv6) address range is subdivided into different prefixes, one of which is designated for use by IP multicast. Receivers typically notify their communication software of their desire to receive messages destined for the multicast group address; this is called “joining a multicast group.” These receiving members then “listen” on the multicast address and, when a multicast message is received at a receiver, it delivers a copy of the message to each process that belongs to the group.
IP multicasting relies on (i) a group management protocol to establish and maintain local multicast group membership, and (ii) multicast routing protocols to route packets efficiently. The Internet Group Management Protocol (IGMP) manages packet communication between hosts and their local multicast router, letting them join or leave groups. That is, IGMP is used to send a group membership message from a host to its directly connected router, indicating that the host wants to join a group (address) as a receiver. Note that IGMP is an IPv4 group membership protocol; the conventional Multicast Listener Discovery (MLD) protocol is substantially similar to, and performs the same functions as, IGMP, but for IPv6. When group membership is established, multicast packets (identified by a multicast group address in the destination address field of an IP header) are forwarded between routers using multicast routing protocols. IGMP Version 3 (IGMPv3) adds support for “source filtering,” i.e., the ability for a system to report interest in receiving packets “only” from specific source addresses (INCLUDE operation), or packets from “all but” specific source addresses (EXCLUDE operation).
Multicast routing protocols construct distribution trees through the network and direct multicast forwarding. The multicast distribution trees define the path that multicast traffic will take through the network to group members. These paths are based on source or shared multicast distribution trees. A multicast distribution tree is shared when any source (host) originating data traffic destined to a group address of a multicast group uses the same distribution tree to forward data to the receivers. In contrast, a source distribution tree is a separate, shortest path tree (SPT) built for each source originating traffic to the multicast group.
A rendezvous point is a specific router that is designated as the root of a shared multicast distribution tree. An announcement protocol is used to select and announce rendezvous points to all routers in the network. However, an alternative to using an announcement protocol to automatically advertise rendezvous points to all routers in the network is to manually configure the identity of the rendezvous points on all of the routers. Examples of such an announcement protocol include the Auto-RP multicast protocol available from Cisco Systems Inc. and the Bootstrap Router (BSR) described in Bootstrap Router (BSR) Mechanism for PIM Sparse Mode, Internet Engineering Task Force Internet-Draft, draft-ietf-pim-sm-bsr-03.txt, by Fenner, et al. February 2003. Examples of multicast routing protocols that use a rendezvous point include Protocol Independent Multicast-Sparse Mode (PIM-SM) and Bidirectional PIM (BIDIR-PIM) protocols. Other multicast protocols that do not require a rendezvous point include PIM dense mode (PIM-DM) and PIM source specific multicast (PIM-SSM) protocols.
IP multicast may be deployed on a computer network using a specific rendezvous point to build a shared multicast distribution tree for a multicast group falling within a destination address prefix or to build a separate SPT for each source originating traffic to the multicast group. Broadly stated, a router joins a multicast group (distribution tree) towards the rendezvous point or source. The interface on the router leading towards the rendezvous point or source is an ingress interface. Depending upon the multicast routing protocol, there is usually only one ingress interface on the router receiving multicast packets for a particular route. One or more interfaces on the router leading towards the hosts (receivers) are egress interfaces. The receivers are leaves or nodes on the distribution tree. Packets are sent from a source to the root (rendezvous point or source itself) of the distribution tree, where they are forwarded towards the branches and out to the nodes that represent the receivers. On each node, packets are received on the ingress interface towards the root of the tree and packets are forwarded out egress interfaces towards the receivers or nodes.
IP protocol of the TCP/IP Reference Model defines five classes of IP addresses. Class D IP addresses, which begin with the bit sequence “1110,” are used for sourcing multicast messages. That is, a host or entity wishing to send a multicast message utilizes a class D IP address. To receive multicast messages, entities typically register with one or more multicast routers. Registration may be accomplished via the IGMP, which defines a set of registration messages and operations that are used by entities to join and leave multicast groups (e.g., JoinGroup and LeaveGroup), and is implemented as part of the IP protocol. Internet Group Management Protocol, Version 3,Request for Comments (RFC) 3376, by Cain et al., October 2002, is hereby incorporated herein by reference as though fully set forth herein.
Specifically, a receiver uses IGMP to communicate a request to join a multicast group address to a last-hop router. The router communicates that request to its neighboring routers (neighbors) on the link towards the rendezvous point (for a shared tree) or source (for a SPT) using a multicast routing protocol, such as Protocol Independent Multicast (PIM). Announcement protocols, known in the art, are used to distribute group range-to-rendezvous point address mapping configuration to all PIM-enabled routers that participate in the network topology. Collectively the routers construct a multicast distribution tree rooted at a rendezvous point or source for that group address and having a branch (link) that “pulls” packets towards the last-hop router. Note that only a single multicast router (forwarder) should forward packets for a route over a specific link of the tree.
A computer network may also be segregated into a series of logical network segments. U.S. Pat. No.5,394,402, issued Feb. 28, 1995 (the “402 Patent”), and U.S. Pat. No. 5,959,989, issued Feb. 28, 1999 (the “989 Patent” that is commonly owned with this application), for example, disclose multicast distributions in a VLAN environment. These patents are incorporated herein by reference. Specifically, according to the '402 Patent, any number of physical ports of a particular switch may be associated with any number of groups within the switch by using a virtual local area network (VLAN) arrangement that virtually associates the port with a particular VLAN designation.
The VLAN designation for each port is stored in a memory portion of the switch such that every time a message is received on a given access port the VLAN designation for that port is associated with the message. Association is accomplished by a flow processing element which looks up the VLAN designation in the memory portion based on the particular access port at which the message was received. In many cases, it may be desirable to interconnect a plurality of these switches in order to extend the VLAN associations of ports in the network. However, since more than one port can be associated with the same VLAN, multicast transmissions will be sent to all those ports, possibly flooding those ports.
To limit the traffic caused by registration messages, only one entity per LAN typically transmits such a request. Other interested entities listen in on the requests of their neighbors and rely on the first subscription request, rather than making their own individual requests, to ensure that messages are delivered to their LAN. Bridges and switches may perform additional filtering so that multicast routers receive only one subscription request per router interface. In particular, bridges and switches may be configured to monitor the IGMP messaging between subscribing entities and multicast routers to learn which of their ports lead either to a multicast router or to at least one entity subscribing to a particular multicast group address. This configuration is referred to as IGMP snooping.
To distribute multicast messages, routers may employ a multicast routing algorithm, such as multicast open shortest path first (MSOPF) or distance vector multicast routing protocol (DVMRP). With MSOPF and DVMRP, routers construct a spanning tree per multicast group address that basically includes all group members. The routers is then build multicast forwarding tables for use in distributing multicast messages. DVMRP, in particular, creates an overlay topology on top of the computer network consisting of several multicast-capable islands interconnected by tunnels. Upon receipt of a multicast message, both MSOPF and DVMRP utilize a multicast forwarding algorithm, such as reverse path forwarding (RPF), to determine whether the message should be forwarded. In response to receiving a multicast message from a particular source, a multicast router using RPF first determines which interface it uses to send unicast messages to the source. If the multicast message was received on the same interface used to send unicast messages, the router forwards the multicast message onto those interfaces that are coupled to subscribers of the message. If the multicast message is received on an interface other than the one used to reach the source, the router discards the message as it is probably a duplicate of a message already forwarded by the router.
Known multicast distribution techniques provide access control lists (ACL) that are implemented at the internetwork layer, L3, of the well known Internet Protocol stack. But ACL's at the L3 layer do not meet the requirements of edge routers with multiple ports connected to a VLAN. An ACL can be configured to accept or deny an IGMP request, but for end users connected by a VLAN to several ports of the respective edge router, the multicast is sent to all those ports. As mentioned above the same limitations exists where the ACL's are tied to specific platforms and where the ports may be flooded with multicast requests and subsequent transmissions. Moreover, configuring such ACL's with two IP source addresses, one for the reporter and one for the channel to be joined under the IGMPv3 protocol is not feasible, and such ACL's lack multicast information base (MIB) support.
Some switching platforms support IGMP filtering using ACL's, but do not implement the source filtering of the IGMPv3 protocol.
Multicast has found its way into cable TV, where providers are sending “video over IP” to end users. This is typically achieved using the Ethernet-to-the-home (ETTH) deployment where video, voice and data are carried over a single Ethernet media to the end users. IP multicast provides for optimal bandwidth utilization, so the content providers multicast video streams via ETTH using PIM-SM (Protocol Independent Multicast-Spare Mode) or Bi-directional PIM.
In the ETTH deployment, each video channel is assigned a unique multicast group address (a Class D address) and the video channel is distributed in User Defined Protocol (UDP) streams to the multicast group address. Each end user has a set-top-box that has an IP stack and an IGMP stack. The user via the set-top-box sends a IGMP join to the edge router which creates the necessary PIM routing states and starts pushing the video streams to the end user. Access lists are currently used at the L3 interface layer. These access lists are defined to accept/deny and IGMP request, but such an implementation will send multicast traffic to all edge router ports that are connected to a given VLAN, possibly flooding the ports. Access lists are also used in some switch platforms, but these suffer from the same limitation as the L3 implementations.
In the known ETTH deployment there is a need for a mechanism where an end user in a VLAN specifies a particular video channel.
The present invention is directed to controlling admission to multicast groups that provides source filtering; implementing multicast distribution that does not flood switch ports; and providing a mechanism for the service provider to implement a service/distribution policy.